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1 . 


INTRODUCTION 


1.1. BACKGROUND 

The Low Cost Booster Technology Program, also known as the Bantam Booster program, 
is a NASA sponsored initiative to establish a viable commercial technology to support the 
market for placing small payloads in low earth orbit. This market is currently served by 
large boosters which orbit a number of small payloads on a single launch vehicle, or by 
these payloads taking up available space on major commercial launches. Even by sharing 
launch costs, the minimum cost to launch one of these small satellites is in the 6 to 8 
million dollar range. Additionally, there is a shortage of available launch opportunities 
which can be shared in this manner. 

The goal of the Bantam program is to develop two competing launch vehicles, with 
launch costs in the neighborhood of 1.5 million dollars to launch a 150 kg payload into 
low earth orbit (200 nautical mile sun synchronous). Not only could the cost of the 
launch be significantly less than the current situation, but the payload sponsor could 
expect better service for his expenditure, the ability to specify his own orbit, and a 
dedicated vehicle. By developing two distinct launch vehicles, market forces are 
expected to aid in keeping customer costs low. 

1.2. APPROACH 

This document is concerned with the ground support and ground operations system for 
the Bantam Program. It is focused on methods of performing the system operations in 
support of a Bantam launch vehicle in a cost effective manner. We are examining two 
special cases of operations, first, operations during the flight demonstration phase of the 
program, and second, standard operations after the vehicle enters commercial operations. 
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2 . 


CASE 1, FLIGHT DEMONSTRATION PHASE 


2.1. OVERVIEW 

The development flight program will demonstrate the performance of the launch vehicles 
produced by the two selected Bantam contractors. The intention of this program is not a 
competition between the vehicles, but rather a pair of flight test programs, with the two 
vehicles having similar objectives. Vehicle performance data will be collected for the 
purpose of assisting the manufacturers in their flight tests, and to provide performance 
information useful for the payload customers in the design of their payloads for launch on 
the vehicles. This data will include recording of all ground system activities during 
ground operations, real-time telemetry from the launch vehicle of critical hardware and 
software parameters, and telemetry collected as available on the payload environmental 
factors. At the completion of the flight test program it is expected that both vehicles will 
be marketed to the low cost launch vehicle market by their respective manufacturers. 

2.2. FUNCTIONAL DESCRIPTION 

The ground support concepts for the flight demonstration program address both the initial 
acquisition and activation of the launch support and control system, and the routine 
support of the test flight program. The system which will be developed for the 
demonstration flights should be fully usable for commercial flights following the 
demonstration program. The following sections describe necessary attributes of the target 
system. 

2.2.1. Multiple Launch Site Support 

Commercial flights are expected to be launched from multiple launch sites. At a 
minimum, commercial spaceports are being developed in Alaska, California, Florida and 
Virginia. The Canadians are developing a launch facility at Churchill Bay in far northern 
Canada, and if the Pioneer Spaceplane option is developed, a spaceport facility will be 
developed in New Mexico. To support this variety, the ground support system will be 
either easily transportable or so inexpensive that it can be replicated cheaply at the 
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multiple locations. As of this writing, the system cost goal appears to be 1 .8 million 
dollars for acquisition, including the display and control system and the simulator. 

2.2.2. Automation 

To meet the cost goal of the Bantam program, a 1 .5 million per launch cost, it is 
necessary to provide support with a small, multi-function team of people which supports 
all aspects of the ground integration and launch support. Very short cycle times for 
launch operations are the norm. Actual launch control and support operations in this 
environment must be highly automated. 

2.3. ALTERNATIVE CONCEPTS FOR GROUND SUPPORT TEAM 

Traditionally, commercial ground operations have been handled by personnel from the 
vehicle manufacturer. This is appropriate when each vehicle is viewed as a part of a 
scientific activity. In order to meet Bantam goals, however it is necessary to treat launch 
vehicles in a fundamentally different way. The goal is to reach a point where the system 
is so routine that when a payload comes in you simply go out to the warehouse, grab the 
next Bantam launch vehicle off the rack, load the payload and launch. The following 
paragraphs provide alternatives on how the ground support team can be effectively 
organized and affiliated. 

2.3.1. Manufacturer centered 

The traditional approach to the ground support team would be for it to be a standard 
service provided by the vehicle manufacturer with the vehicle. This approach provides a 
team that is highly knowledgeable about the vehicle. The team oriented operations 
methodologies described in this document apply directly to this type of team, with the 
exception that some of the handover points would probably be less formal, and the 
vehicle integration would likely be supported more by personnel from outside the 
immediate launch team. 

2.3.2. Independent 

A second way to establish the ground support team would be to form an independent 
organization to support launch services for both vehicles. This approach has the benefit 
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of reducing duplication of efforts in forming multiple launch teams. This also strengthens 
the establishment of common payload interfaces and standard operations procedures 
across payloads and spaceports. An independent team can be much more focused on 
payload users and on the aspects of operations which apply specifically to payload 
operations. Marketing the low cost launch vehicle generically, rather than individual 
vehicles specifically, may be a more powerful way to expand the small satellite launch 
market. 

2.3.3. Spaceport centered 

Another potential method of operations would be for the spaceports to have a dedicated 
Bantam team for all Bantam flights. This team could support either of the Bantam 
vehicles, and would be able to gain efficiency through high levels of integration of range 
safety and range operations. If the ground system is as automated as is envisioned, and 
given the simplicity of the vehicle, it should not be difficult for such a team to operate. 
Currently the spaceports do not see this as within their charter, and it appears to be the 
least likely of the approaches. In the following discussions this option is not elaborated, 
as it would appear to be costly to duplicate the launch team at each spaceport. It is 
possible that at some point in the future there may be enough traffic at some spaceports to 
support such teams. 

2.4. STANDING TEAM DESCRIPTION 
2.4.1. Rationale 

The reasoning behind forming a standing team of payload operations personnel is that a 
team of this nature will significantly enhance the routine nature of Bantam operations. If 
the program is to succeed at providing launch services at the target prices, it will do so 
through a large number of launches. This implies high launch rates, and simple, lean 
procedures which allow high launch rates. These factors in turn imply a high degree of 
automation, and a small, (to keep costs down) well trained core of workers to accomplish 
these launches. 
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2.4.2. Composition 

The assigned members of the operations team will depend to a certain extent on the 
affiliation of the team, as described above. If the team is employed by the launch vehicle 
manufacturer it is likely to be smaller, since some of the functions of the team are likely 
to be assumed by Bantam project engineers. As launches become more routine the 
numbers can be reduced further. 

An independent ground support team would be expected to be composed of a Program 
manager and a core of operations engineers. The current concept is based on three 
operations engineers handling up to six launches per year. Each of these individuals will 
serve as lead for two missions in process, and would be directly involved in supporting all 
launches. This team would be responsible for all aspects of the launch planning, 
preparation, and conduct. They will negotiate with the payload sponsor, vehicle 
manufacturer and spaceport to develop cost and schedule for the mission. They will 
coordinate all required licensing and mission analysis. They will be responsible for 
configuration management of the ground support system hardware and software, and 
verification and management of all delivered flight software loads. 

The entire Bantam ground support team will monitor the launch countdown for every 
launch. The full launch team will encompass range safety personnel, and it will be 
beneficial to include at least one representative from the vehicle manufacturer to provide 
vehicle specific expertise during the flight demonstration phase. This is a very lean 
launch team, made possible by extensive automation of the display and control software. 


2.5. GROUND SUPPORT PHASES 
2.5.1. Initial ground system activation 

For the demonstration phase at least one complete ground system will be developed, and 
the procedures for operating it will be put in place. The following sections describe the 
one-time acquisition, integration and verification activities necessary to accomplish this. 
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2.5.1. 1. Operations plan generation 

The plans required for running the ground support center will be generated prior to the 
demonstration flights. Essentially the same plans will be used for the commercial phase 
of the operations. To accomplish this it is desirable for the ground team to be established 
early enough in the demonstration program for them to fully participate in early design 
reviews, and ensure that the ground system is fully integrated into the overall system 
design. 

2.5.1. 2. Control Center hardware and software acquisition and integration 

Computer equipment, telemetry acquisition and control center hardware and software will 
be designed, acquired, integrated and tested by the ground support team. The essence of 
the ground station is a group of workstation based consoles which are either portable or 
easily transportable to the desired launch site. The option of providing standard outfitting 
at all sites may be investigated with the spaceports at a later date, but for the flight 
demonstration phase a single center should suffice, and would probably be most 
economical. 

Software is available off the shelf, and the only significant drawback to existing software 
system is that they contain features which are not required by the operational Bantam 
system. Existing ground support software packages are highly configurable, and provide 
methodologies for automating the launch process to a high degree. They operate in a 
variety of operating environments, including Windows NT. The primary integration task 
is to configure the system for Bantam support. The automation required for this program 
means that the system will have the ability to conduct and evaluate launch operations 
with minimal external inputs. This in turn requires a significant effort in defining proper 
systems performance for the software. This modeling and the verification that the model 
is correct are the primary integration activities for the ground support software. 

2.5.1. 3. Mockup acquisition and validation 

A physical mockup of the vehicle to payload interface will be built during the 
demonstration phase. This must be maintained and used to ensure that payload interfaces 
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are complied with on both sides, payload and vehicle. This item will consist of a mockup 
of the mating assembly for the standard payload interface, connectors for electrical power 
from the vehicle, data connections for the sensor data (this is the one difference between 
the DFI interface and the standard payload interface) and umbilical connections for 
prelaunch communications with the payload. This should be a relatively low cost item, 
less than $20K. 

2.5.1. 4. Mission Planning Software acquisition and validation 

The mission planning system is used to generate flight software for the On Board 
Computer (OBC) for the specific mission to be flown. This software package is 
developed by the vehicle manufacturer. During the demonstration phase the 
manufacturer will be the sole user of this software. The verification of this flight 
software in operation is one of the prime objectives of the flight demonstration program. 
Verification of the mission planning system is therefore primarily the responsibility of the 
manufacturer. 

2.5.1. 5.Simulation acquisition and validation 

The capability to verify that the flight software produced for an individual mission is 
correct and error free is essential to the long term success of the program. In order to 
effectively determine that the production flight software load performs as designed it is 
necessary to test it in a simulator which contains the actual flight control computer or a 
very accurate emulation of the flight control computer. This allows the ground support 
team to upload the software (in the best of all cases using standard upload procedures for 
the vehicle), run through a detailed prelaunch checkout, and fully simulate an actual 
flight. The output of the simulation can then be used in comparison with the actual 
telemetry to analyze vehicle actual performance compared to theoretical values. In 
addition, this simulation will be useful to the ground support team in evaluation of the 
performance of the system monitoring functions of the control center software. 

This simulation is a vital design tool for the vehicle manufacturer, and should be their 
responsibility to build. Portions of the simulation are relatively simple, since the Bantam 


8 



vehicle is relatively simple. Flight control computer stimulation or emulation is not 
simple, and is key to an adequate system. A hardware and software development cost of 
830K is estimated. This has been included in the $1.8 million cost mentioned earlier 

2.5.1. 6. Development Flight Instrumentation (DFI) acquisition and 
validation 

The DFI package is conceived as a standard set of instrumentation to be flown on all 
demonstration vehicles. This establishes and enforces interface standards, ensures a 
common set of reference data, and provides a cost savings to the vehicle manufacturers in 
the area of flight instrumentation. One design decision which should probably be made 
early in the process is if this package is to be expendable or recoverable. An expendable 
package must be relatively low cost, simple to manufacture, and still robust enough to 
return all required data. It would provide an ancillary benefit of allowing small, low cost 
payloads of the sort many universities wish to fly a “free” ride. Given that this payload 
would be specifically designed to fly on Bantam it would also have the potential of being 
the basis for a standard payload package for payload sponsors to use as the basis for 
Bantam class payloads. A recoverable package can be reused for multiple flights, though 
it would be necessary to produce backups to account for high flight rates and the 
possibility of an catastrophic event destroying the entire vehicle. 

Data to be collected by the DFI is based on collection rates such as defined in the Low 
Cost Boost Technologies Fastrac 60K Engine Interface Definition Document. Less than 
150 sensor measurements are expected at a 50 Hz rate. The DFI will directly collect data 
on acoustic, vibration, thermal and structural loads on the payload, and data from 
additional sensors desired by the vehicle manufacturer. Adding this to the other sensor 
data indicates that less than 500 data points need to be transmitted at a 50 Hz rate. This is 
a relatively low rate, and well within the capabilities of economical systems. 

Additionally it is expected that the command stream generated by the flight control 
computer(s) will be monitored and recorded for later download. This data is not needed 
in real time, and it should be easy to recover by downlink from the payload, or directly, in 
the case of a recoverable payload. 
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The estimated cost for a recoverable DFI payload is approximately 3 million dollars. To 
be economical, an expendable payload should cost less than a quarter of that (based on 
two expendables, and two launches per manufacturer). As the number of launches in the 
development cycle is increased, so is the total cost of expendable test payloads. Even 
with this taken into account, it should be realistic to produce an instrumentation package 
with the required capability for under $750K. 

Establishing the DFI as a separate deliverable item is desirable in several aspects. First, it 
is an ideal item to be produced by a small business, or possibly as a research project in a 
university. Secondly, it could become a viable commercial product in its own right as the 
basis for a standard Bantam payload architecture. 

2.5.1. 7. Configuration management system acquisition and checkout 

The premise on which the low cost of the Bantam vehicle is based is that of a launch 
vehicle which is a commodity. That is, each vehicle produced by the manufacturer is 
essentially identical to every other. The only difference between individual launch 
vehicles is the flight software which controls the mission. A well defined method for 
controlling, verifying and managing the flight software loads for multiple flights is 
essential. Off the shelf commercial products which can handle this task are readily 
available. The key factor is compatibility with all vehicle manufacturer systems. 

2.5.2. Flight test program 

Figure 2.5.2. 1 shows a representative timeline for high level ground support activities in 
support of a demonstration flight. 
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Figure 2.5.2.1 High level mission timeline 

The actual flight test program will be carried out to look as much as possible like the 
expected commercial operation. This allows operational procedures to be developed and 
validated, and provides essential training for the ground support team. Figure 2.5 .2.2 
shows the low level processing steps during the launch process. 
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Figure 2 . 52.2 Launch processing steps 
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2.5.2. 1. Mission Definition 

Definition of the specific mission details by the customer will be accomplished prior to 
each Bantam flight. For the demonstration program this data is likely to be available 
further in advance of the actual flight than would normally be the case in actual 
operations. The preliminary mission determination and the detailed payload and mission 
specifications should be available significantly in advance of the actual flight. This data 
is the input required by the mission planning software system to use to build the vehicle 
flight software. For the demonstration flights the manufacturer is expected to perform all 
of the activities necessary to generate the flight software load and deliver it to the launch 
team. 

2.5.2.2. Launch licensing 

The vehicle manufacturer traditionally has been responsible for obtaining the license for 
the flight. During the demonstration program this will be the case for the early launches, 
but this may be an appropriate function for the ground support team to assume. The 
expected lead time for licensing from the Office of Commercial Space Transportation is 
180 days, but a single license can cover all of the launches in the demonstration flight 
program. 

2.5.2.3. Range safety analysis 

A detailed analysis of the flight vehicle range safety considerations will be conducted for 
each launch, however the initial flight of the vehicle will require an extensive analysis of 
self destruct capabilities, proposed flight path monitoring and all other aspects of the 
range safety plan for the vehicle. A significant portion of this analysis is a one time 
expense, however some aspects of it will be repeated for each flight. 

2.5.2.4. Test flight software verification 

Delivery of the flight software for the vehicle is expected to be separate from the vehicle 
delivery. For purposes of software checkout the simulator will look to the ground system 
like an actual launch vehicle. Software uploads will use the standard interface out of the 
ground system into the simulator, and the simulation will run a full scenario from fueling 
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through payload release, with the standard ground system monitoring activity as if the 
simulator were the actual vehicle. The full data recording capability of the ground system 
will be employed to capture data used for post flight analysis. The essential elements 
which are tested are the predicted vehicle performance, to ensure that the flight software 
acts as expected and that the desired orbit is achieved, and the trajectory of the vehicle to 
ensure safety margins are adequate, and to establish a baseline predicted trajectory for the 
actual flight. In addition, during early demonstration flights the ground support software 
is evaluated fully in these simulations. 

For demonstration flights the actual verification of the software is likely to be 
accomplished by the vehicle manufacturer, and collection of data from the flight itself 
will be a part of the verification of the software during post flight analysis. The 
simulation will be used extensively by the ground team as soon as it is available for 
evaluation of software and procedures for simulations as well as ground launch 
operations. 

2.5.2.5. Vehicle/DFI Integration 

Integration of the data collection package will be accomplished using the standard 
procedures established by the ground support team. Vehicle to payload integration for the 
early demonstration flights will be primarily performed by the manufacturer’s team, with 
the direct participation of the ground support team in the process. This is an area where 
ground support teams from the manufacturer have an advantage, as they will probably be 
drawn from the vehicle engineering team. Specific integration procedures will be quite 
vehicle specific, and ground handling equipment will likely be as well. The most robust 
expendable system would appear to be a manufacturer furnished transporter, erector, 
launcher (TEL) which could be used at any of the available launch sites without having to 
rely on the spaceports to provide the same equipment at each site. The rocketplane 
approach requires integration of the payload with the upper stage which will provide the 
final orbital insertion, and an integration of that stack with the carrier plane. Typically 
this full integration is performed in a hanger type of environment, allowing a great deal of 
ease in payload handling, and flexibility in integration. 
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2.5.2.6. Launch servicing 

Vehicle servicing is expected to be carried on by spaceport personnel, with oversight 
from the launch support team. An important aspect of the Bantam concept is to use 
simple, robust technology. The expectation is that the vehicles will use standard 
propellants, LOX and RP-1 or liquid hydrogen being the baseline cases for this analysis. 
This implies that all of the infrastructure, including safety procedures and systems, is 
already in place at the spaceports to handle uploading fuel to the vehicle. In some cases 
the spaceports are proposing using servicing vehicles for fueling operations, which would 
allow operations from a bare pad. 

2.5.2.7. Launch 

Launch control by the ground support team is a matter of overseeing what is primarily an 
automated procedure. Once the sequence is initiated the launch control software 
monitors physical parameters, such as tank pressure and temperature, environmental 
parameters, such as weather conditions, and verifies proper OBC software execution. 
Built in holds during the sequence are expected to give the team an opportunity to review 
the status of all systems, and manual abort is always available. Other than that, the 
ground control computer will act autonomously, and turn operations over to the flight 
computer at the appropriate point in the countdown. 

During flight real time telemetry may be displayed, and critical health monitoring 
parameters will be made available to the range safety personnel. The only ground control 
team function during this time is for mission abort destruction sequences. 

2.5.2.8. Data collection 

Two major classes of data will be collected during each demonstration flight, real time 
and on board archived data. 

2. 5.2.8. 1 . Real time data 

Data collected from the vehicle (and the ground system event log) are archived and 
displayed in real time. It is efficient and easy to collect the prelaunch operations data this 
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way through the umbilical link. Real time downlink from the launch vehicle is more 
difficult to collect, and collection adds to the cost of the system in the form of more 
complex avionics systems and ground telemetry acquisition systems. It is essential, 
however, that key data parameters be made available for health monitoring from the range 
safety point of view, and that necessary data for analysis be provided in the event of a 
catastrophic launch failure. Selection of the key parameters to monitor for anomaly 
investigation is essential. 

2.5.2.8.2. Non-real time data 

There is a subset of data which provides information on vehicle performance which does 
not have any intrinsic real time value, but is key to the final analysis of vehicle 
performance. Typical data might be detailed information on vehicle bus traffic, vibration 
information, thermal conditions and g forces encountered during launch by the payload. 
This data can be collected and written to an on board storage device for downlink on a 
later orbit, or direct recovery from a reusable, recoverable instrumentation package. 

Either method allows the real time downlink to be simplified and made more robust, as it 
will have less demand for high rate data. 

2.5.2.9. Data reduction and analysis 

Data collected during prelaunch operations, real time launch data and collected non-real 
time data will be made available to customers, vehicle manufacturers, spaceports, 
sponsors and other interested parties for detailed analysis. Collected data will be archived 
electronically and provided as a part of the final program report along with the 
appropriate analysis. The archive should provide time tagged computer logs of all ground 
system activity, time tagged raw data stream of all data from the umbilical, and the time 
tagged non real-time data downloaded from the payload. 

2.5.2.9.1 . Launch system performance 

The non real time data mentioned above is key to post flight analysis for the purpose of 
defining expected environmental conditions to potential payload customers. The report 
on this analysis will be prepared and presented as an appendix to the vehicle to payload 
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ICD. This data is essential to the design of payloads for an appropriate launch vehicle, 
and can also be expected to be a discriminator for the payload sponsors to use during the 
selection of a vehicle to launch their payload. 

2.5.2.9.2. Simulation comparison and validation 

Data collected by the flight demonstration will be compared to the simulation data for 
improvement of the simulation, and updates to theoretical and analytical models of the 
system performance. 

2.5.2.9.3. Data integrity and security 

Two distinct types of data are being collected during these demonstrations, the 
engineering data to be used by the manufacturers, and secondly the performance data 
which will eventually be provided to the payload sponsors for use in satellite design. The 
engineering data could be highly proprietary, and must be protected appropriately by 
ground system operations. During the demonstration flights there should be no occasion 
for remote access to the launch control center software, so it will be isolated from the 
outside. Engineering data will be available only to the manufacturer . The mission 
planning, simulation software system and flight software will also contain proprietary 
data and models, so security is an aspect which must be considered in the configuration 
management and control of these systems. 

2.5.2.9.4. Review ground operations procedures and update operations plans 

A final review of operations plans in preparation for implementation in the operational 
phase will be conducted. 

2.5.3. Demonstration Program Wrap-up 

Products from the demonstration program should primarily be those necessary to support 
commercial operations. The following should be considered as a minimum. 

2.5.3. 1. Revise operations plan as necessary for operational modes 

Experience obtained during the demonstration flights will carry over directly into 
operations. By the completion of the demonstration phase there should be a well 
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established set of routine procedures for the ground support system. A particularly 
important byproduct of the demonstration program is a set of trained ground system 
engineers. These individuals form the nucleus of the ground support system for the 
operational program, and they and their skills and knowledge must be retained. 

2.5.3.2. Prepare payload ICD and preparation procedures 

The standard vehicle to payload ICD is one of the tools which enable the low cost 
paradigm in the Bantam system. By ensuring a standard interface between the payload 
and each launch vehicle payloads can be designed to be launched on any available 
vehicle. This lowers the cost of payload design, and encourages price competition to 
drive down launch costs. Consideration should be given in definition of this ICD to 
making provisions for attachment of secondary payloads, which are not supported by the 
primary payload sponsor, and require only very minimal support from the vehicle. 

2.5.3.3. Assist primes in preparation of vehicle performance reports 

The operations team will be particularly important in post flight analysis of vehicle 
launch preparation, servicing and control systems. In addition they can assist in post 
flight dissemination of telemetry, both real-time and non-real-time. 

3. CASE 2, STANDARD OPERATIONS PHASE 
3.1. OVERVIEW 

The commercial use of the Bantam vehicles is dependent on establishing a new paradigm 
for space operations. For the Bantam program to be successful the vehicles must be 
treated as commodities rather than as programs. That is to say, the operation must be 
made so routine that launch planning and execution have essentially no impact on the 
program. The launch vehicles from a manufacturer must be so nearly identical that the 
only vehicle preparation necessary is uploading the flight software and fuel, and the 
interfaces must be so standard that a payload sponsor can build a satellite and then go out 
and simply acquire the next (or least expensive) launcher available. 
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One driving factor in the current world is the cost of insurance. In the Bantam concept, 
the launch vehicle is so inexpensive that the nature of this cost is shifted. The design of 
the launch vehicle reflects this emphasis, with importance placed on design robustness, 
but some degree of uncertainty accepted when it would affect costs. 

The expectations of payload sponsors in this concept should be based on the view that 
cost is the driving factor. This implies, for example, that some systems which would 
have hot spares in place in today’s world, would simply be allowed to delay the launch or 
not used in the case of failures. 

A launch control center in this environment would look very different from today’s 
standard. Instead of rows of consoles, there would be a few workstations. No 
complicated internal communications system is needed, because all of the operations 
personnel are right next to each other. Standard, interchangeable PC’s or workstations 
will be used both for low cost and ease of backup in the case of failure. Hot backups and 
spares are not required in this concept, as potential launch delays are part of the risk the 
payload sponsor assumes within the low cost launch concept. The display and control 
system should be stable, with no worry about changes from one launch to the next. The 
only updates required for a launch are those required to account for the specific mission 
flight software and trajectory. 

3.2. FUNCTIONAL DESCRIPTION 

The model for the operational phase of the Bantam system is different from the standard 
way space missions are currently conducted. Rather than an individually developed 
mission, each Bantam launch is conducted as a routine activity, with only the actual 
payload being different from one mission to the next, and the only real difference there is 
the weight and orbital destination. Unless this type of approach is achieved it will be 
difficult to meet the cost goals of the program. 
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3.3. ALTERNATIVE GROUND SUPPORT TEAM CONCEPTS 

Essentially the same set of alternative operations teams concepts applies in this phase as 
in the development phase. The decision on which approach to take is independent of the 
approach used in the development phase, though this may be interrelated. In commercial 
operations the independent team approach has some distinct advantages. It allows the 
payload sponsors to contact a single organization, which essentially acts as an honest 
broker in negotiating the best launch deal for them. This relieves the payload sponsor of 
the need to negotiate for the best launch deal. The effect should be to foster a user 
advocate paradigm, enhancing the competitiveness of the system. It avoids the 
duplication of having independent teams for each vehicle, making the goal of routine 
launches much easier to achieve. It enhances the probability that the standard payload 
ICD will be enforced, thereby reducing design uncertainties for the payload sponsors. 

3.4. STANDING TEAM DESCRIPTION 

A standing team for launch control allows rapid turnaround for launches, consistent 
enforcement of standards, and consistent and well defined procedures and methods for 
continuing improvement of launch control procedures. In the operational era we expect a 
minimal team, making use of fully automated ground support hardware and software. A 
basic four person team is envisioned, three operations engineers on the launch team, and a 
systems engineer with overall responsibility for the functioning of the team. One launch 
team member would act as the lead for each mission. This lead individual would be the 
person responsible as the primary point of contact between the payload sponsor and the 
Bantam operations. This duty would rotate among the team members, so each would 
normally be responsible for two or at most three missions. As the number of Bantam 
launches increases operations engineers would be added as needed to retain this basic 
ratio of personnel to launch missions. The simplicity of the vehicle to payload interface 
is expected to allow the ground support team to actually perform the physical integration 
of the vehicle and payload. The hardware to run the system probably must be portable, 
since it is likely that multiple launch sites will be used, and the cost of outfitting each 


19 



launch site, and maintaining the software and hardware configurations would be 
prohibitive. 


3.5. GROUND SUPPORT PHASES 

Figure 3.5.1 shows the top level mission phases and timeframes for an operational 
environment. 
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Figure 3.5.1 Operational launch phasing and timeline 

Appendix A provides a checklist with specific internal and external activities associated 
with each of the phases above. The following sections describe these phases in more 
detail. 


3.5.1. Mission definition 


3.5.1 .1 . Request for flight 

The initial contact from the payload sponsor to the ground support organization begins 
the mission definition process. At this time the data required from the payload sponsor is 
relatively generic, primarily desired orbit, launch date and weight. This is the point at 
which the scheduling and negotiation begin. In the case of an independent ground team 
the operations engineer assigned to the flight would initiate contact with the spaceports 
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and launch vehicle manufacturer to determine schedule openings and vehicle availability. 
In fact, they would likely be working together on a day to day basis, so most of this 
information would be on hand for the ground team. The operations engineer would 
initiate negotiation to obtain the desired schedule and best price, along with all viable 
options. This would be presented to the payload sponsor to select the desired vehicle and 
launch site combination. In the case of a ground support team integral to the 
manufacturer the process would be similar, except that the payload sponsor would have to 
contact both vehicle manufacturers, and they would in turn contact the spaceports. 
Similarly for the spaceports if they control the ground team, they would contact the 
vehicle manufacturers for the best deal. 

3.5.1. 2. Detailed mission definition 

Once the vehicle, spaceport and launch date have been tentatively selected, the payload 
sponsor would be expected to provide detailed data on the vehicle and desired launch 
parameters to the ground support team for coordination. This package contains all the 
information necessary to support safe handling of the payload, including information on 
special handling required, on board propellants, and any hazardous materials handling 
requirements. The orbital data required is the detail of orbital parameters, weight and any 
other specific data deemed necessary. At this point in time it may be possible to take 
advantage of excess booster capacity to fly opportunistic payloads. These are usually 
small, inexpensive projects, typically produced as course work at universities, which can 
be flown with major benefits with little or no notice, and only minor support required. 
The ability to coordinate this type of activity is one of the ancillary benefits of an 
independent launch team, but this could be done under any of the proposed organizations, 
if appropriate provisions are made to solicit projects. 

Typical time frames for these activities would have the initial contact several months 
prior to flight and detailed data package delivery shortly thereafter. Licensing has a 
potential impact on this timeline, however a programmatic license will allow for multiple 
standard launches with a significantly reduced turnaround. The Office of Commercial 
Space Transportation has indicated that meeting the anticipated Bantam turnaround 
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should not be a significant problem. In the final expected environment it would be quite 
reasonable to be able to turn around a payload in a month or less. This assumes that the 
flight vehicles have already been manufactured and simply need to be shipped to the 
launch site (or taken out of a storage facility at the site). 

3.5.1. 3. Optional services 

This is the point where desired optional services will be defined by the payload sponsor. 
Typical optional services we might expect to be requested are: 

• Remote access to launch operations via Internet access 

• Expanded payload telemetry during ground operations 

• Payload telemetry during launch 

• Participation of sponsor personnel in integration and launch activities 

3.5.2. Mission planning 

The detailed information on required orbital parameters is the input for the mission 
planning process. The primary output of this process is Operational Flight Program 
(OFP) which executes in the vehicle. In the environment of a standardized set of Bantam 
vehicles, this is theoretically the only significant difference from one vehicle to the next. 
Generation of this software could be performed by either the vehicle manufacturer or, if 
the mission planning software is sufficiently automated, by the ground support team. The 
mission planning software itself is a byproduct of the development process, and if the 
ground support team is to run it, it must be procured by them from the manufacturer. The 
output of this process is an OFP which must be tested, controlled by the ground support 
team and uploaded to the vehicle On Board Computer (OBC) during preparation for 
launch. 

Due to the high degree of automation expected in the flight planning process and the 
relative simplicity of the Bantam flight software, OFP generation should be accomplished 
in a few days at most, so this is not a schedule driver. To support other activities, the 
minimum delivery time would be 30 days prior to launch. 
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3.5.3. Flight product verification 

The verification of the OFP is essential to ensuring success of the flight. Since this is the 
only significant difference between the vehicles from one manufacturer, it is also the 
primary controllable variable between flights. The simulation produced by the 
manufacturer as part of the development process is the tool which is used to perform this 
verification in the operational mode. The activities are essentially identical to those 
carried on during development, except that there is more emphasis on understanding the 
flight profile for the launch activity, and little or no emphasis on post mission analysis. 

The timeline for this activity is short for the actual verification, essentially taking the 
same amount of time as an actual mission. There may be several simulations run, for 
familiarization, training and also to benefit payload sponsor personnel supporting the 
flight (these missions often have an educational purpose which is as important as the 
scientific purpose of the payload). The month between delivery of the OFP and the flight 
should give sufficient time to perform as many of these simulations as desired. If there is 
much impact on the ground support team this may be a chargeable item to the payload 
sponsor. 

The second flight product which must be verified is the payload itself. When it is 
delivered to the ground support team, they will integrate it with the mockup to ensure that 
physical, electrical and data interfaces are appropriately configured. A simple electrical 
and data interface integrity check will be accomplished at this point. As built weight 
measurements are made for final verification prior to flight. 

The timeframe for the mockup testing is immediately after delivery of the payload, one 
month prior to launch. The activity itself should take less than a week. 

3.5.4. Vehicie/payload integration 

Once again, the vehicle to payload integration is almost identical to the analogous process 
during development, with the exception that the data interfaces for the DFI are no longer 
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required. This simplifies the process slightly, but even the DFI interfaces are minimal, so 
this is not a significant saving. During the demonstration program this function was 
performed largely by vehicle manufacturer personnel with ground support team 
participation. For operational launches the ground support team would be expected to 
perform the actual physical integration as part of their standard activities. Given the 
straightforward interfaces, it does not appear cost effective to use dedicated personnel to 
perform these tasks. 

Since the payload interfaces were tested well prior to the actual interface to the final 
launch vehicle, this integration should take very little time. The expected time to begin 
final integration is 48 hours prior to scheduled launch. 

3.5.5. Servicing 

There should be no difference at all in operational servicing. The ground support team is 
in an oversight role during this activity, concerned primarily with ensuring that the 
Bantam procedures are followed correctly. The ground support team provides the 
spaceport with the vehicle and payload specific expertise on the launch vehicle. They 
will become experts in the specific procedures of each spaceport. This is typical of the 
reason for having a dedicated team, to ensure continuity throughout the launch program. 

3.5.6. Prelaunch checkout 

Payload requirements for monitoring during ground operations are minimal, so the 
prelaunch checkouts are less demanding than for the demonstration program. With 
current launch vehicles the sponsors of Bantam class payloads typically have no ability to 
monitor payloads flying as add-ons on someone else’s launch. Simple health monitoring 
and possibly the ability to command the payload to a ready mode are all the capabilities 
which are envisioned. 

For commercial operations the recording of detailed data on the progress of the launch 
sequence should no longer be necessary. The only utility of the data is in analysis of 
anomalies, and close attention needs to be given to determine if this is worth the cost. Do 
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not assume that this is a free capability just because it was developed during the 
demonstration phase. Maintenance of the software, analysis of results and archiving data 
are not free. The key to this question is insurance, and the willingness of the insurance 
carriers to underwrite a launch without the ability to do a detailed post flight anomaly 
analysis. Once again the achievement of a routinely successful, high number launch 
record is likely to be necessary to allow this. In the ideal environment we would consider 
a “no fault” insurance viewpoint, that is a case where the cost of a replacement launch is 
low enough and the probability of success on the second try high enough that anomaly 
resolution is not worth the higher per launch cost. 

3.5.7. Launch sequence 

During the launch sequence itself events should be the same as for the demonstration 
flights, except for the absence of the RF link to the DFI, and the noted lack of a need to 
monitor internal operations. Participation desired by the payload sponsors is uneven, 
some desire considerable observation and participation, others are only interested in 
knowing that their satellite is in orbit. The desire has been expressed to monitor launch 
operations remotely, perhaps through an internet connection. This should be possible at a 
relatively low cost, however our recommendation is still to avoid even low cost services 
which do not directly contribute to the mission, as the resultant set of inexpensive 
capabilities could be significant, and would consume resources which are in short supply. 

3.5.8. Post launch activities 

The only significant post launch activity is verification for the payload customer that his 
payload has been delivered to the specified orbit. This may be accomplished by 
telemetry, ground tracking or any other method to verify orbital parameters. The second 
question which may be asked is whether the specified environmental conditions for the 
launch were achieved. This is important in the case of a payload failure to assess the 
reason for the failure. Once again the tradeoff discussion is the same as it was for launch 
monitoring, whether the cost is worth the reduction in risk of loss in the case of payload 
failure. Here the question is if the payload sponsor is willing to accept a higher level of 
risk to obtain the lower cost. If a significant history of successfully meeting specified 
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conditions can be established during the early operational flights this should be a 
reasonable request. From discussions with payload sponsors this does not seem 
unreasonable. In the current state of affairs it costs at least 6 to 8 million to launch a 
typical payload in this class. A typical payload of this type costs about 1.5 million to 
produce. As a result the sponsor could in effect buy his own insurance by building and 
launching a backup payload in the case of a failure, and still be significantly better off 
than they are today. 
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APPENDIX A 


GROUND OPERATIONS CHECKLIST 
GENERAL INFORMATION 

The attached checklist provides an overview of the specific internal and external activities 
during each of the preparation phases for an operational mission. 
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External Data and Products 

Mission Definition Phase: 

Collect following from requester: 

• Type of payload 

• Safety considerations (propellants, 
etc) 

• Ground handling considerations 

• Approximate weight 

• Desired orbit 

• Desired launch date 

• Desired vehicle 

• Requested participation 

• Optional services requested 

Mission Planning Phase 

Collect following from requester: 

• Exact payload weight (as built 
measurements will be made after 
delivery) 

• Exact orbital parameters required 

• Confirm launch date 

• Confirm optional services 
Mission planning organization 
performs following: 

• Generates flight software load and 
documentation 

•Performs necessary internal testing 

Flight Product Verification 

Manufacturer 

• Prepares and ships vehicle 
Payload sponsor 
•Prepares and ships payload 


Ground Support Team Activities 

Contact appropriate launch sites to confirm 
schedule availability, and request launch 
services bid 

Contact licensing agency for launch 
Contact manufacturers for bid on launcher 
Generate price quote for optional services 


Schedule launch 

Provide mission planning organization 
(could be ground support team) with 
detailed payload data 

Accept flight software and places under 
configuration control 

Perform and document range flight and 
ground safety reviews 


Upload flight software to simulation and 
verify predicted performance 

• Trajectory 

• Final orbit 

• Predicted launch environmental factors 

Mate payload to mockup and ensure all 
interfaces are correct 

Perform simulations and rehearsals of flight 
as necessary 
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Integration 

Integrate payload and flight vehicle 

Integrate range safety package (as required) 

Input mission specific data into ground 
support software 

• Predicted trajectory 

• Applicable flight software checkout 
data (program checksum, internal 
performance data, etc) 

• Servicing data 

Launch 

Vehicle servicing support 

Service payload 

Upload flight software 

Perform (automated) prelaunch hardware 
and software checkout 

• Monitor servicing 

• OBC test program 

Sequence launch (automated) 

• Vehicle launch progress monitor and 
control data displayed on consoles 

• Go/no go pauses in sequence provide 
for manual confirmation 

• Automated hand-off to OBC for launch 

• Monitor downlink (if provided) 

Post Launch 

Obtain and provide payload sponsor with 
actual payload orbital elements 

Perform any desired post launch analysis 

Furnish requested recorded data 
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